Current computer device operating systems store configuration data in a configuration file located in long term, frequently called permanent, memory. Computer devices include, but are not limited to, desktop and laptop personal computer, personal digital assistant (PDA), cellular telephone, etc. Configuration data includes file associations, hardware, operating system and installed application settings, display, printer, and other connected peripheral settings, performance data, etc. (collectively, hereinafter “user preference”). When changes are made to the user preference, the changes (or dirty data) are written in a configuration file in a computer device memory located in short-term memory, frequently called Random Access Memory (RAM).
At regular time intervals, the dirty data is flushed from the short term memory to a log file located in long term memory before the dirty data is written to the configuration file located in long term memory. Long term memory includes the hard drive of a desktop or laptop computer or the flash memory of a PDA or cellular telephone, for example.
Every time the computer device is turned on, the operating system loads the user preference stored in the configuration file located in long term memory into short term memory for applications to execute according to the changes made to the user preference. For example, in a computer device that includes a Windows® type operating system, a configuration file stored on a hard disk is called a hive primary file (hereinafter HPF), a configuration file stored in memory, e.g., RAM, is called a registry hive file or an in-memory hive file (hereinafter, HMF), and a log file stored on the hard disk is called a hive log file (hereinafter, HLF). Accordingly, when user preference changes are made, the changes are written to the HMF before the changes are flushed from the HMF to the HLF and subsequently written from the HMF to the HPF. Windows® loads the contents of the HPF into RAM for applications to execute according to the changes made to the user preference. Maintaining the user preference stored in the configuration file on the hard disk (i.e., the HPF) current as user preference changes are made is critical if applications are to execute according to the latest changes made to the user preference. The user preference stored in the configuration file on the hard disk (i.e., the HPF) may not be current, i.e., may not include changes made to the user preference if a computer device “crashes” or a transient error occurs while writing from the configuration file in memory (i.e., the HMF) to the configuration file on the hard disk, (i.e., the HPF). Since the configuration file in memory, the HMF, is deleted when the computer device is shut down, as usually occurs when a computer device “crashes”, the “dirty data” stored in the log file, i.e., the HLF, is loaded into memory when the computer device is turned on the next time. Dirty data comprises changes made to the user preference not yet transferred to the HPF. In the case of a transient error, while changes to the user preference continue to be written to the configuration file in memory (which is deleted when the computer device is shut down), the operating system prevents the dirty data from being written to the configuration file on the hard disk or flushed to the log file. As a result, the incomplete dirty data in the log file is loaded into memory when the computer device is next turned on.
FIGS. 1A and 1B form a flow diagram 100 illustrating an exemplary sequence of events that might occur when changes are made to a user preference. The changes may be either successfully or unsuccessfully written to a configuration file on a hard disk of a computer device, depending on whether a crash or transient error occurs. While FIGS. 1A and 1B illustrate exemplary sequence of events in the computer device operating a Windows® operating system, it is to be understood that the similar events may occur in computer devices controlled by other types of operating systems. Flow diagram 100 begins at block 101 when a change is made to a user preference. The change, called dirty data, is written to a registry hive file (HMFo) at block 102.
FIG. 2A is a pictorial illustration of an exemplary prior art HMFo 200. HMFo 200 includes a header section 201 subdivided into two, where each subdivision holds an integer. The integers match (illustrated by “A” in each subdivision) before dirty data is written to one or more data sections 202, 203, 204, . . . of the HMFo 200. The integers remain matched until the dirty data is flushed to a hive log file (not shown). When the dirty data is flushed to a hive log file, the integers become mismatched. Mismatching occurs before the dirty data is written to the hive primary file (not shown). The data sections 202, 203, 204, . . . of HMFo, shown below the header section 201, change in size and number depending on the amount of dirty data to be written to HMFo 200. In the example shown in FIG. 2A, two of the data sections 203 and 204 contain dirty data, as illustrated by a sequence of “Xs.” The other illustrated data section 202 includes clean or unchanged data. It is to be understood that each data section could contain dirty data for more than one user preference or the dirty data for one user preference could overflow from one data section into another.
Returning to FIG. 1A, at block 103, a check is made to determine if a flush operation to flush the HMFo is either initiated by a user or a “lazy flush” has been initiated. If the check fails (the “NO” branch from block 103), a further check is made at block 104 to determine if there is more dirty data to be written to the HMFo data sections. If the further check fails (the “NO” branch from block 104), the flow cycles back to block 103. If the further check succeeds (the “YES” branch from block 104), the flow cycles back to block 102. If the check at block 103 succeeds (the “YES” branch from block 103), at block 105, the header section of HMFo is written to a header section of a hive log file (HLFo). Next, at block 106, a dirty vector is written in HLFo. Next, at block 107, the dirty data is written from HMFo to corresponding data sections of HLFo.
FIG. 2B is a pictorial illustration of an exemplary prior art HLFo 205. HLFo 205 includes a header section 206 subdivided into two. The header section 206 contains an “A” in each subdivision (written at block 105 in FIG. 1A). Below the header section 206 is a dirty vector section 207. The dirty vector section 207 contains location information for the dirty data in the data sections of HMFo 200 that contain dirty data, namely, sections 203 and 204. Comparing FIG. 2A with FIG. 2B reveals that the location information for the dirty data in sections 203 and 204 is written at block 106 in FIG. 1A, into the dirty vector section 207 of HLFo 205.
HLFo 205 also includes data sections 208, 209, 210, . . . shown as located below the dirty vector section 207. Similar to HMFo 200, the data sections of HLFo 205 change in size and number depending on the amount of dirty data to be written from HMFo 200 to HLFo 205. In this example, data sections 209 and 210 of HLFo 205 contain dirty data written from data sections 203 and 204, respectively, of HMFo 200. The dirty data (written at block 107 in FIG. 1A) is represented by a sequence of “Xs”.
Returning to FIG. 1A, at block 108, a check is made to determine if the dirty data needs to be written from HMFo to a hive primary file (HPFo). As illustrated in FIG. 2C and described below, the structure of HPFo is similar to the structure of HMFo. In other words, HPFo includes a header section subdivided into two, each subdivision holding an integer, and data sections corresponding in size and number to the data sections of HMFo. If the check fails (the “NO” branch from block 108 in FIG. 1A), the flow continuously cycles back to block 108 until the check succeeds. When the check succeeds (the “YES” branch from block 108), at block 109 (FIG. 1B), the header section of HMFo becomes mismatched. Next, at block 110, the mismatched header section of HMFo is written to the header section of HPFo. Next, at block 111, the dirty data is written from the data sections of HMFo to corresponding data sections of HPFo.
FIG. 2C is a pictorial illustration of the status of an exemplary prior art, HMFo 200, HLFo 205 and HPFo 211. HMFo 200 and HLFo 205 are the same as in FIGS. 2A and 2B, respectively, with some changes in the header section of HMFo 200. More specifically, HMFo 200 of FIG. 2C contains a mismatched header section 201 (illustrated by “A” and “B” in the two subdivisions that become mismatches at block 109 of FIG. 1B). The header, vector, and data sections of HLFo 205 remain the same as at the end of block 107 in FIG. 1A. HPFo 211 includes a mismatched header section 212 (illustrated by “A” and “B” in each of the two subdivisions as written at block 110 in FIG. 1B). HPFo 211 further includes data sections 213, 214, 215, . . . illustrated as located below the header section 212. Data sections 214 and 215 contain dirty data (illustrated by a sequence of Xs) written at block 111 in FIG. 1B. The dirty data in sections 214 and 215 of HPFo 211 correspond to the dirty data in sections 203 and 204, respectively, of HMFo 200.
Returning to FIG. 1B, at block 112, if a check determines that the computer device has not “crashed” or a transient error has not occurred before all of the dirty data is written from HMFo to HPFo (the “NO” branch from block 112), at block 117 the header section of HPFo is matched.
FIG. 2D is a pictorial illustration of the status of the exemplary prior art HMFo 200, HLFo 205 and HPFo 211 showing the header section matching that occurs at block 117 of FIG. 1B. These two subdivisions of the header sections of HMFo 200 and HLFo 205 remain the same as in FIG. 2C. The two subdivisions of the header section 212 of HPFo becomes matched (as illustrated by “A” in both subdivisions).
Returning to FIG. 1B, at block 118, since the dirty data is successfully written to HPFo, the user preference from HPFo is loaded into memory when the computer device is turned on the next time, and the flow cycles back to block 101.
If the computer crashes before all of the dirty data is written from HMFo to HPFo (the “YES IF CRASH” branch from block 112), at block 114, the user preference from HLFo is loaded into memory when the computer device is turned on the next time. The flow cycles back to block 101. If a transient error occurs before all of the dirty data is written from HMFo to HPFo (the “YES IF TE” branch from block 112), a further check is made at block 113 to determine if HMFo needs flushing. More specifically, the further check is made to determine if the user has made further changes to the user preference written to HMFo since the last flush operation at block 103. If the further check fails (the “NO” branch from block 113), no more dirty data was written to HMFo after the last flush operation. In this situation, even though the transient error occurred before all of the dirty data was written to HPFo, the dirty data in HLFo is valid. If the further check fails, at block 114, the user preference from HLFo is loaded into memory when the computer device is turned on the next time. The flow cycles back to block 101.
FIG. 2E is a pictorial illustration of the status of the exemplary prior art HMFo 200, HLFo 205 and HPFo 211 at block 114 in FIG. 1B if the further check fails or the computer device “crashes” before all of the dirty data is written. HMFo 200 and HLFo 205 remain the same as in FIGS. 2C and 2D. In addition to HPFo 211 containing a mismatched header section 212 (illustrated by “A” and “B” in each of the two subdivisions), one of the data sections 215 of HPFo 211 contains incomplete dirty data (illustrated by a sequence of Xs in data section 215 that is less than the sequence of Xs in data section 204 of HMFo 200).
Returning to FIG. 1B, if the further check succeeds (the “YES” branch from block 113), additional dirty data was written to HMFo after the last flush operation. In this case, at block 115, the dirty data written to HMFo after the last flush operation at block 103 cannot be flushed to HLFo. In this case, the dirty data in HLFo is only complete up to the last flush operation. Dirty data created after the last flush, up to when the transient error occurred is not in HPFo. At block 116, the (incomplete) user preference from HLFo is loaded into memory when the computer device is next turned on. Because the user preference is not complete, the user will have to redo the changes to the user preference that occurred after the flush operation (block 103). Next, the flow cycles back to block 101.
FIG. 2F is a pictorial illustration of the status of the exemplary prior art HMFo 200, HLFo 205, and HPFo 211 at block 115 in FIG. 1B. HMFo 200 contains dirty data written in data section 202 (illustrated by a sequence of Xs) that occurs after the flush operation at block 103 in FIG. 1B. HLFo 205 remains the same as in FIGS. 2B, 2C, 2D, and 2E. HPFo 211 remains the same as in FIG. 2E above for the same reason.
Even though most current computer devices use a log file of the type generally described above to log changes made to a user preference, some systems that control several computer devices use dual copies of the log file. The dual copies are stored on two different computer devices in an effort to ensure that both copies are not impacted by a “crash” or transient error in one computer device. Since the content of the dual copies is identical before the “crash” or transient error occurs, changes made to the user preference after the “crash” or transient error cannot be written to the configuration file of the computer device experiencing the “crash” or transient error. This means that user applications running on the computer device experiencing the “crash” or transient error will not execute according to all changes made to the user preference, until a system administrator matches the dual copies of the log file.
As will be appreciated from the foregoing discussion, current operating systems that use a log file or dual copies of a log file may not always write all changes made to a user preference before a “crash” or after a transient error. Since most users are unaware of the transient error, most users will not realize that changes made to a user preference were not written until an application does not execute according to the changes made to the user preference. As a result, users are required to redo the changes made to the user preference prior to when the computer device “crashed” or the transient error occurred, that were not written to the user preference before the crash or transient error.